-
Notifications
You must be signed in to change notification settings - Fork 11
chore: update Python version #753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
the default is now 3.7 on FreeBSD.
Travis error is unrelated:
just means newer mypy version is now detecting better… things? |
make sure it comes in the correct version
what, even, are packages? and what are dependencies? huh??
|
A couple of days ago I upgraded my server to FreeBSD 12.1-RELEASE and used this branch to upgrade my years old libiocage to libioc + ioc. I used this branch to install and am now encountering the same issue as you do in your test run, namely a "Dataset xyz is not mounted". It occurs when creating a new jail and also when fetching a new release:
Altough the dataset is actually mounted:
Digging through the codebase, I traced the issue back to the I added a sleep before the mountpoint is checked and ran a script in a loop to check the mountpoint using both libzfs and libioc.ZFS.get_zfs(), but both reported the mountpoint correctly every time. I have no idea what the issue is here, but since I am interested in a fix I thought I'd shar my findings here. If there is anything I can do (testing, etc.) I'd gladly help out. I can reproduce the issue in @gronke's Test script for reference: #!/usr/bin/env python3.7
import libzfs
import libioc
dataset_name = "zroot/iocage/releases/12.1-RELEASE"
stdzfs = libzfs.ZFS()
ioczfs = libioc.ZFS.get_zfs()
def check(zfs):
normal = zfs.get_dataset(dataset_name)
root = zfs.get_dataset(dataset_name + "/root")
print(f"normal mountpoint: {normal.mountpoint}")
print(f"root mountpoint: {root.mountpoint}")
print("without libioc zfs:")
check(stdzfs)
print("with libioc zfs:")
check(ioczfs) BTW, shouldn't you also change the python version for the |
well, that's probably a good idea |
I'm seeing the same problem with
|
Also same problem creating new jails. |
Not sure if it helps but I reverted py-libzfs from 20191113 to 20181220 and error seems to go away |
.. on it.. @igalic want to join me in tmux? |
i should look at the diff between those two |
The regression was introduced with ZFS parallel mounts in FreeBSD 12.1: |
@gronke so should I open a separate ZFS ticket? |
Let's start collecting everyone's kernel and py-libzfs versions in #755 |
An issue exists, yes. Right now I'm further investigating the problem. Its deterministic across systems, built with or without the commit mentioned above. Before opening a ticket for FreeBSD, I'd like to have reduced my PoC to the minimal steps to reproduce without involving py-libzfs. A hotfix to address this issue is to re-open ZFS handles for all operations involving mounts. At the same time it requires changes across the entire library and comes with a huge performance penalty. Rather than working around the issue, a custom C module tailored for ZFS operations of libioc seems more appropriate. We do know exactly what operations to perform on ZFS datasets, so this a good opportunity. Be assured that there will be a hotfix for 12.1 as soon as I have fully understood the impact of the regression. Next step is a debugging session with @fabianfreyer on tmux. After that I should be able to provide a PoC that's worth a ticket on FreeBSD, reason about a short-term solution for libioc and maybe even find motivation to optimize ZFS workflows. |
Commits have been incorporated in #751. |
The hotfix was to disable mnttab_cache in |
the default is now 3.7 on FreeBSD.